hi hello everybody i hope that you are enjoying the congress and i hope that you enjoy my
presentation for the next 45 50 minutes i will talk about hardware attacks hardware security
more specific i will talk about fall injection and i will talk from my experience as professional
evaluator that has been using pole injection and other hardware techniques for testing products so
maybe you don't know what is full injection so the first thing i will do is make a short
introduction before to pole injection then i will talk about real attacks on the real world
products that have been hacked and then i will introduce some of the techniques or some of the
tests we do on the products we evaluate and finally i will talk about protection
and how to prevent these kind of attacks so let's start with this let's take a look at this code
this is a code i took from somewhere from a product
it's kind of the code iphone this code authenticates a pin or a password if you take a
look there is three software vulnerabilities three problems so an attacker can bypass the
pin check or the pin authenticator or the pin authenticator or the pin authenticator or the pin
authentication in three different ways so first here in red i mark
there is a problem with this loop that iterates through the password through the pin
this loop only iterates as many bytes as the user provides so if the user provides one single byte
as password of pin only one byte will be checked then here there is a buffer overflow
the software does not check how many bytes you provide as a pin so the buffer can be all the way in one bit
flow and the attacker can get runtime control of the target and finally we
have format stream vulnerability so all these three attacks are very common are
very well known and they are very easy to fix so this could be a possible
solution in blue there is the changes that will fix this software so we fix
the loop we put a limit to the number of bytes we get as a password or as a pin
and finally we format properly the string so is this now secure well from
the software point of view probably it is I don't find a way that you can attack
this code from the software point of view I think that all the issues are
fixed but if the attacker has physical access to the device that is running
this
software if he can use get this device because this is running on a smart card
or on a IOT or embedded any kind of embedded device and has access to it
then the attacker can try hardware attacks and I will talk today about one
hardware attack which is fault injection and this code has at least four places
where you can inject a fault and you can bypass this this check
because it only takes a
check in red here here here and here so I will explain what is wrong with these
sentences and why you can bypass the tech here but before that let me
introduce myself my name is Ramiro and I am a technical lead at risk your
security lab in China so I were actually here in China we have a security lab
here in China in Shanghai my company is specializing in hardware evaluations we
evaluate chips we evaluate socks better system IOT devices automotive mostly
hardware sometimes some software also we also do hardware we develop hardware for
testing the security hardware security ok so let's talk out fall injection how
this works so if we take the documentation of a chip if we have a
chip that has been used to develop a device
you would check the documentation of this tip there will be probably
something like this in the data sheet or in the manual we will find a plot like
this which indicates what is the safe area what is the voltage you can use to
power this chip sometimes it's a plot like this
sometimes it's a a table but the manufacturer tells that the steep can
operate between one point and nine percent improvement the chip operating
volts and 5.5 but what happens here in this area in red in red so if we try to
power the tip with one below 1.8 volts or 5.5 what happens when the factors
will not tell you they will only say that the behavior is undefined so what
actually is happening okay so it's it's obvious that if we power the device at
five point above the specifications for some time we will hit the tip and we
will kill it we will burn in the same way if we operate the tip under voltage
for some time we will put the tip to we will switch it off we will put it to
sleep it will not be powers
so we will not work but the question is what happens when the tip is going
beyond the specifications for a very short period of time so for a just few
nanoseconds or few microseconds we exceed the voltage limits above or below so
this is what we call a glitch and this glitch might introduce a fault in the
tip and an attacker by doing these glitches daddyplex we can get some
benefits of the tip so let's see what happened inside it did so this is my CPU
this is a cheep is powered with external power supply this CPU is composed of
different modules has our medical logical unit as a control unit is run
cast
and all these models are powered
using a power distribution network.
Inside the chip there is a network that powers a different circuitry.
If we look at this distribution, this power distribution,
some modules are closer to the power pins, some modules are farther,
so some power lines are longer and some are shorter.
This power line, for example, is very close to the pin where the chip is powered,
so the power distribution line is very short.
The control unit is powered with a long power line,
because it's farther from the pin, and because it's longer,
the resistance, when the currents flow through this line,
the resistance will be higher.
The different modules will have different lengths in the power line
that distributes power.
These different modules have different capacitance.
This resistance and this capacitance create filters.
When I inject a glitch, this glitch, not all the modules inside the chip
will see the same way.
Depending on the shape of the glitch, how long is the glitch,
how deep is the glitch, what is the shape, some circuits will filter
the glitch and some others will not.
In this example, I have here the arithmetical logic unit,
because it's very close to the power pin, the resistance of the power
distribution line is very small, the filter is very small,
so the glitch, if an attacker injects a glitch, it will be affected.
But the control unit will not, because it's farther and it's filtering
the power better.
An attacker, by injecting different glitches with different shapes,
can affect different modules inside the chip.
What exactly can he get when he injects the glitches?
We have these effects.
An attacker can get the following.
The first is that he can disable the modules.
We saw before, here, during the period of time
that we are glitching the device, the chip,
during that period of time, the arithmetical logic unit
is under power, so it's not going to work,
while the rest of the chip is working normally.
And after the glitch, everything works and operates normally.
So an attacker can try to inject glitches,
hoping that a hardware security module or feature in the chip
will stop to work during this small period of time
that the glitch takes place.
But something that an attacker can also expect when injecting glitches,
is flipping bits.
Flipping bits stored inside the chip, on the memory of the chip.
So this is a flip-flop.
This circuit is the standard memory cell.
This is the basic unit that stores information inside a digital circuit.
So any SRAM, any register in a CPU
is composed of many of these flip-flops in series.
It can store only one single bit.
So here, this flip-flop is storing one bit,
and the value is one.
It's what we see in the Q output of the top right.
So if an attacker injects a glitch,
and this glitch makes the power of the gate, of the flip-flop,
to go lower than the threshold level,
the voltage threshold level,
for the decision of whether the gate is getting a one
or whether it's getting a zero,
the NOR gate will see, instead of a one in this place,
will see a zero.
And this zero will be propagated through the flip-flop.
Then, when the voltage, when the glitch is over,
and the voltage gets normal,
we, the flip-flop remains,
will keep the value of the,
the value, the flipped value of the,
will keep the value we flipped.
So, using a glitch,
we managed to change the content of a memory cell
from one to zero.
But we can do the same to flip from zero to one.
So it operates in the same way.
So, what else can we get with glitches?
So with glitches, we can also corrupt the code
that is being executed in the, in the CPU.
So this is the code I showed you at the beginning.
And I told you that here,
the red line is a place I can inject a fault.
I can use glitching to bypass the secure,
the secure check, the pin check.
So why this happens?
If we take this sentence in C,
and we compile in ARM, for example,
we have this assembly code.
These three instructions do the same
that we have here in C.
If we look at how the branch,
the assembly instruction for the branch,
the branch is encoded,
if we look at this,
this is how the branch is encoded.
Because we have a tool which is the glitches.
We can use the glitches to flip bits.
If we use a glitch,
and this glitch happens to flip one of the bits
in the instruction that is being executed,
the CPU will execute the instruction in a different way.
So in this example here,
if we flip the first bit from one to zero,
I will not execute a branch.
I will be executing a store instruction instead.
So my code changes completely.
Here in the top left,
you can see what is the actual code I've been executing.
So with one glitch,
I can change the flow of the code,
I can change how the code is executed.
Another example.
The next instruction in the assembly,
the store,
is encoded like this.
If we glitch up and we change one of the bits
from one to zero,
the instruction is executed in a completely different way.
Again, we change the flow,
we change the code,
how it's executed,
we change the software that the chip is executing.
So an attacker can inject glitches,
hoping that he will flip the bits that he needs
in order to change the software in the way he is looking for.
To skip instructions,
or to correct the code,
or to interrupt instructions,
or to do whatever he wants.
What else?
An attacker,
when he's trying to inject glitches,
sometimes because we are putting the chip above
or under the recommended voltage,
sometimes we can destroy the chip.
This is something as an attacker we don't want,
but sometimes we will kill the chip,
we will kill the CPU.
But this doesn't happen too often, to be honest.
Okay, so this might be a bit strange for you,
that you can use voltage glitches
to just change the code that is being executed
and bypass security protections in a hardware device.
It sounds strange,
but the truth is that this has been used
for many, many, many years already.
And there is many things that have been hacked,
using full injection.
And now because we have all these new IoT devices,
and because the security,
the software security is being increased,
many hackers found out that nowadays it's easier
to hack an IoT device or embedded device,
it's easier to hack using hardware techniques
than using software techniques or software attacks.
So for that reason nowadays,
basically almost every few months,
we see a new attack,
somebody that is doing something with full injection
and is getting some results.
So I took this from Twitter a few weeks ago,
somebody was publishing,
he managed to break embed TLS using full injection.
A couple of years ago in DevCom,
there was somebody who was presenting
how to bypass the authentication of a Tresor,
a Bitcoin wallet, using full injection.
And it's a video game arcade machine.
But 30 years ago,
kids were using these lighters that have a spark,
spark lighters,
that when you press the button there is a spark.
So they were using this spark to shock the arcade machine
or the video game machine and play for free.
And this was 30 years ago,
and this was a way of doing full injection or glitching,
and kids were doing this even without knowing it.
Funny thing is that still nowadays,
30 years later,
this is a very common attack.
I found this video on the internet.
This is a guy who sells this device.
This is a device who makes full injection,
is doing glitching,
not with voltage,
but with EMP,
electromagnetic pulses.
So this small device generates electromagnetic pulse,
and this pulse generates a glitch.
So he's putting this device close to the electrode,
the electronics that counts the coins,
and you can see here,
the counter that counts how many coins
you insert in the slot machine.
And it's increasing,
as long as he's pressing the button to glitch.
And he can play.
So he can just play and try to get the price of the machine.
So this is an example,
another example of real world full injection attack.
Okay.
So these attacks have been there for long.
And some industries know this.
So some industries like smart cards
have been tested against full injection
for many years already.
And I have been doing this,
testing against full injection for quite a long time now.
So I will explain some different tests
or different attacks we do on real products,
on real products that we evaluate.
And this is a test for customers.
So before going through these examples,
I want to introduce you the first rule of full injection,
which is everything can be hacked with full injection,
unless you protect against this kind of attacks.
And the second rule is that even if you protect your product
against full injection,
it might be hacked.
Because full injection is really difficult to prevent.
And there are many ways that it can be used
to attack a product.
So let me show you some examples.
I chose five different examples of tests we do on real products
where we use full injection
to try to bypass some kind of security.
So the first one is bypassing authentication.
This is what I explained before here,
this pin authentication.
I have some demos.
I brought with me some tools.
So if you are interested to see this in real life,
I have my tools in my bag.
I wanted to do some demos,
but it's very hard to do demos here.
So I made a video yesterday of this.
This is the tool we use for injecting glitches.
So the green board,
the small green board,
is an ARM processor.
It's just a small embedded device with an ARM chip.
And the green box,
the green-yellow box,
or the yellow box,
the big yellow box,
is the tool we use to inject glitches.
So this tool powers the CPU
and you program it in such a way
that you inject a glitch when you want.
So I made a program
that is trying to bypass authentication
of this code I show you here.
So what this program is doing
is waiting for the chip to send you the message,
insert a pin,
sending 000 as a pin,
in that moment injecting a glitch,
and reading the response.
If the glitch succeeds to bypass authentication,
then I will have a pin correct.
If not, I will have a pin incorrect.
Sometimes I will have a response which is random garbage
because sometimes the chip crashes.
So this is the operation of this attack
I made a video yesterday.
So most of the times we see that the pin is incorrect
because we don't succeed on glitching properly.
And from time to time,
this will be a pin correct.
Here, there it is.
So this was one attempt.
We have to try many times
until one of the glitches
affects the chip in such a way
that bypass the software
the way we are looking for.
And sometimes these lines,
which are empty,
is because we crashed the chip.
Because probably the software crashes
or jumps somewhere.
I don't know.
This kind of test,
trying to bypass authentication schemes,
we use this a lot on smart cards.
Basically, there is no smart card nowadays
on the market
that has not been tested
against this kind of fall injecting attacks.
We also test this a lot in smart meters.
Smart meters, they have a debug interface.
So an operator can physically go to the meter
and debug it.
And there is an authentication protocol
to be able to debug the smart meter.
We recently tested a couple of Bitcoin wallets
and password wallets.
Basically, any kind of device
with some kind of Linux.
Normally, with Linux,
you have a UART port
with some kind of shell
and you need to know
the password to go in.
You can bypass quickly using fall injection.
And also automotive.
It might be not trivial
why or where
there is some authentication scheme in a car.
We use fall injection to bypass UDS.
UDS is a protocol,
a diagnosis protocol
that is implemented
in most of the cars in the market
or most of the new cars.
This protocol
allows
to get locks from the car,
do some diagnostics on the car.
So if something is failing,
you can use this protocol
to see what is failing.
And one of the features of this protocol
is that you can extract the firmware
and you can change the firmware.
You can allow the new firmware.
So this is very interesting
from the hacker point of view.
If you can recover the firmware
and then you can change
and put it back or something like that.
So how this,
well,
to prevent hackers
to access to this protocol
and get the firmware
or modify the firmware,
there is some kind of authentication scheme.
This authentication
is just basically a challenge response.
The car sends a random number.
The random number is encrypted
with a secret password.
The response is sent to the car
and if the response is correct,
the car allows you to debug
using this protocol.
So we can use fall injection in the car
or in the ECU,
which is the computer of the car,
to bypass this check.
So probably there will be a code like this one
where we check if the key
that we receive is the correct one.
If not,
we just jump to a place
that probably will reset the car
or will just ignore the authentication.
So we can just check
and let's use a glitch
to corrupt these instructions
in such a way
that they are not executed.
Okay.
What else we can do?
We test a lot of secure boots.
So secure boots,
probably you know,
is a security feature
that is implemented in many SOCs
and many CPUs
and many devices
to be sure that
only software
that has been signed
and has been authorized
is running on the device,
on the CPU.
So normally this is ROM code
that is in the chip
that at boot time
authenticates,
calculates the signature
and authenticates the signature
of the software
that is stored in the flash
before loading into the RAM
and executing the code.
And normally there is a chain.
So there is like different faces,
different stages
where we are authenticating
different parts of the firmware.
This is used a lot in smartphones
to prevent anybody
to just put any firmware
or custom ROM in the phone,
especially if your phone supports TE.
And we test a lot of this.
We test a lot of secure boots in phones
to check if they are secure.
We also test a lot of pay TV systems
or smart TVs.
And basically,
almost nowadays,
almost any IoT device
or embedded device
have this secure boot.
So routers,
or cameras,
whatever.
Almost every device
has one of these secure boots.
And we test them
to be sure that nobody can use
fall injection to bypass them.
How can you bypass a secure boot
with fall injection?
Well,
if we have a tool
that allows us
to skip instructions
or to corrupt instructions,
then it's very easy to do it.
Whenever there is,
well,
when the secure boot
is checking the signature
of the next state,
we can just inject a glitch
and prevent the execution
of that check
and bypassing it.
So this is a code
of a simple secure boot
that loads the plus image
and then calculate the hash,
check the signature,
and then compare the hash
and the signature.
So here in this code,
we can inject the glitches
in many different places.
So like here,
or here,
here.
So all these red lines
are different places
that we can easily inject a glitch
and bypass a secure boot.
But the problem here
is that a secure boot
is kind of complex.
And there are many,
many,
many ways
to bypass it.
There is many,
many,
many instructions
that when we corrupt them,
we can just escape
the secure boot
and bypass it.
And this is something
that is very complicated
to protect.
So I was introducing before
the second rule
of fall injection,
which is that
when you protect,
you want to protect
your device
against fall injection,
you try to do your best
and sometimes you fail
because it's very hard
to protect it.
So,
when we,
we have many customers
that try to protect
their secure boot
against fall injection.
And they find
the most obvious places
where we can inject glitches
and they protect these places.
But then,
we test the product
and we find
that there are many
different places
that they didn't consider
that you can inject
a glitch
and bypass a secure boot.
And sometimes
it's not obvious.
So we develop a tool.
We develop a tool
which we call
Fall Injection Simulator
that simulates
all the possible glitches
on the code
and it tells you
which ones
will allow you
to bypass
the secure boot.
So this tool
is this one here.
We load the secure boot
or any code
we want to test
and then
we'll compile
for the platform
that this test
is going to,
this code
is going to be running,
ARM,
normally.
And then,
we test
and we can just
press the button
simulate
and it will try to,
it will compile
the code
and will try to simulate
all the possible glitches
on all the instructions
of the code.
After running
the simulation,
well,
it will take
some time
to find
all the glitches
in the right side.
Here in the right side
we have
the different glitches
that the tool finds.
It takes
around
five minutes
to do this.
It depends,
of course,
on the size
of the code.
This is
of all the possible glitches.
These are
instructions,
assembly instructions
that
if you inject
a glitch
and you flip
one single bit
will allow you
to bypass
the secure boot.
So with this tool
we can easily identify
potential
vulnerabilities
in the code
and
try to mitigate
those,
those vulnerabilities.
I have
this tool
here
in my computer
if you want to see
how it works.
Just let me know.
I will be around
in a minute.
So,
more attacks
we test.
We test
escalation
of privileges.
So,
quite often
we are
in the situation
that we have
a product,
we have
a device
and we have
only restricted
access
to this product.
And we want
to break out
of this restricted
access
and be able
to execute
or
get full control
of the box.
So this
happens in
many scenarios
but the most
two common ones
are when
we have
user space control
and we want
to break
into kernel space
or we have
RE control
and we want
to break
and get control
of the TE.
So,
just to put
an example,
breaking
the TE,
there is
a technique
we use a lot.
We call
this
wild jump
attack.
I will explain
how it works.
This is
a TE system.
This is
a
memory
segmentation
of a
TE system.
The RE
can only
access
to the
RE memory
and the TE
can only
access
to the
TE memory.
There is
a shared
memory
which is
the mailbox.
So when
the RE
wants
to send
a message
to the
TE,
this is done
through the
mailbox.
Put the
message in
the mailbox
and the
TE will
read it
and the
other way
around.
So,
this attack
works as
follows.
The RE
who is
under control
of the
attacker
because maybe
the attacker
can run
an application
on the
RE,
the attacker
puts a
message
and then
he spries
the memory
with the
payload
address.
He spries
the rest
of the
mailbox
and indicates
the TE
that there
is a
message
to read.
The TE
will read
this message
normally
using a
main copy
or some
kind of
similar
function.
And this main
copy what
normally does
is load
from an
address,
copy to a
register,
and then from
the register
to a
different
address.
So,
if the
attacker
injects
a
glitch
when the
address
of the
payload
is being
copied
and this
glitch
happens to
affect
the
user
like this,
what we
have
is that
we
copy
the
payload
address
directly
into the
program
counter,
into the
PC.
So,
we are
basically
forcing
the
CPU
of the
TE
to run
or payload.
And then
the attacker
gets
full control
we use
this kind
of
attacks
as in
all these
devices I
mentioned
before in
phones,
normally in
phones where
there is a
TE and we
want to
test if
we can
break the
TE to
access to
the secrets
of banking
applications,
of payment
applications.
We use
this with
Linux systems,
Linux products,
and we use
this in
Android phones
or devices
to see if it's
possible to
root these
devices.
And we
do this a lot
on any kind
of device
that implements
arm
trust on
TE.
OK,
something else
we test.
We try
to recover
crypto keys
using
Poly Injection.
This is
quite complex.
There are many
different ways
of doing
this and
there are
many
techniques,
there are
many papers
published out
there that
explains how
using Poly
Injection you
can get
keys from
a system.
So I
will not go
through this
full analysis.
This is called
full analysis.
I will not go
through this
because it's
very complex.
This basically
is based on
the cryptographic
algorithm in
such a way
that this
glitch affects
the internal
state and
by analyzing
how the
glitch or
how the
error that
you introduce
is propagated
you can try
to recover
the key.
This is very
complex.
I will not
talk about
this.
I will talk
about something
simpler which
is that many
devices that
works or
operates
with
cryptographic
many devices
that have
crypto engines
they normally
have a key
slot.
This key
slot is a
place in
the memory
or region
or registers
that stores
all the
keys and
these keys
goes to
the crypto
engine and
normally these
keys in the
key slot
there are
attributes.
These attributes
indicate
which key
can be
used with
AES.
The key number
one can
only be used
with AES
because in the
attributes it
says that it's
only possible
to use with
AES.
If somebody
tries to
tell the
crypto engine
to use the
key number
one with
this it
will not
work.
The engine
will not
accept the
operation
because the
key has
no permissions
to be used
with this.
So here we
can use
pole injection
to change
this
attribute
table in
such a way
that we
allow
operations
that we
were not
supposed
to do.
So now we
for example
in this
case we
change the
key number
one so we
can use
with this.
Why we
want to
do this?
Because this
is very easy
to break.
We can
brute force
this.
So we
can use
pole injection
to force a
key to go
into the
desk engine
we can then
use brute
force to
recover this
key.
We use
this in
all the
devices I
mentioned
before plus
white box
crypto.
White box
crypto is
a kind
of
obfuscation
technology or
kind of DRM
technology.
It's not the
same but kind
of DRM
technology.
It's a way
to obfuscate
the crypto
operations and
we use
this pole
injection to
recover the
keys from
this white
box crypto.
Finally,
my final
attack or
final
example,
modifying
security
configuration.
So if
a chip
or a
features have
to be
initialized at
some point.
Normally this
happens during
the secure
boot or
this happens
at boot
time.
There is a
software that
enables the
security
features.
Like for
example,
it blocks
the
JTAG or
enables the
memory
scrambling or
I don't
know,
whatever.
So this
normally happens
at boot
time.
So because
we saw how
glitches can
be used to
bypass
instructions or
to corrupt
instructions,
we can use
glitches to
prevent the
initialization
of these
security
features.
But there is
something else
we can do.
After the
system is
initialized,
after the
system is
running and
the security
features are
initialized,
there will be
somewhere in
the chip
one bit
that indicates
that the
security
feature is
enabled.
So if we
can inject
a glitch and
change that
bit from
one to
zero,
we can disable
this feature.
And we can do
this glitching.
To try to
flip this
bit, we
will need to
try a lot of
times before
glitching the
specific bit
we are looking
for.
So there is
a different
technique.
We can use
what we call
localized
fall
injections.
This is a
tool that
allows you
to inject
a glitch in
a specific
part of
the chip.
So if
you know
where is
this bit
that you want
to flip
located in
the chip,
with this
tool,
you can
just flip
only that
bit.
So we use
electromagnetic
fall
injection,
electromagnetic
pulses,
like the
video of
the slot
machine I
showed you
before,
only that we
have more
precision
because it's
a proper
tool.
And we also
use lasers.
We use
the laser
to hit
the surface
of the
chip and
the photons
will open
or close
transistors
making
the bits
to flip
from one
to zero
from zero
to one.
This video
shows how
we use
lasers to
test a
chip.
So this
chip is
again an
ARM
processor.
This is
actually the
laser.
We are shooting
with the
laser on
the surface
of the
chip.
So what we
are doing
is we
want to
disable
a
feature.
We know
there is a
bit
somewhere
that
disables
this
feature.
So what
we are
doing
is inject
a
laser
with a
pulse.
Try to
see if
the feature
is
disabled.
If not,
we go to
the right.
We move
the laser
a bit to
the right
and we
inject a
glitch again.
And we
try and
try and
try until
we find
which is
the place
that when
we inject
a glitch
with the
laser,
we flip
the bit we
are looking
for.
This is
a setup
of an
EM
pole
injection.
Here we
are using
an EM
transient
probe to
do the
same
on a
board.
Okay.
And I have
been talking
about pole
injection
attacking.
I am
going to
talk now
about preventing.
we can
choose
hardware
protections or
software
protections.
Which one
is better?
The thing
is that
rule number
three,
if you
want to
protect
your
product,
you have
to use
both.
Hardware
and software
contra
measures.
The
problem is
that most
of the
times we
are just
using a
third-party
chip.
We are
using a
chip from
somebody else.
We don't
have control
on the
hardware.
So we
cannot make
changes on
the chip to
protect the
chip against
pole
injection.
So we
have to use
only software
contra
measures.
Still,
it will not
be perfect.
If you
use only
software
contra
measures or
protections,
it will not
be perfect.
But it
will improve
the security
of your
product really
a lot.
Really.
So if we
use hardware
contra
measures,
normally
what we
use is
we put
in the
chip,
we put
sensors.
We put
sensors that
detect when
the voltage
is going
down or
up very
fast.
And if we
detect this
glitch,
we can just
reset the
chip.
Or we
can add
redundancy.
So we
want to
protect a
bit that
we know
that an
attacker
wants to
flip it
because it
is a
bit that
see bits.
So if
somebody
flips this
bit,
the parity
will detect
the flip
and then
the chip
will,
well,
you can
reset the
chip,
you detect
that there
is a
glitch,
a
parity
mismatch.
Software
contra
measures,
we
can use
many
techniques to
follow the
security of
your
system.
So this is
the code I
have before.
And with
a single
glitch,
one single
glitch,
we can
bypass
this
authentication.
So how
to prevent
this?
We copy
paste the
code twice.
So we
put the
code twice
so the
attacker can
glitch the
first time,
but the
time that
you
product
check the
condition
will
find.
So we
can copy
paste the
checks.
Of course,
the attacker
can do a
double
glitching.
He can
glitch twice,
but this
is much
more
complicated
than a
single
glitch.
Okay,
here,
if we
just
manage to
glitch the
first time,
the second
time that
we check
will detect
the glitch.
Okay,
something else
we can do
is
software
countermeasures,
something else
we can do
is adding
random delays.
The idea
is that
the attacker
needs to
inject the
glitch when
the instruction
that he
wants to
corrupt is
being executed.
So if
we add
a
random
delay
before this
place that we
want to
protect,
the attacker
will not
know when
this
instruction
is going
to be
executed.
So he
will not
be able
to inject
the glitch.
So this
is a
very
effective
way to
prevent
glitches.
There are
I will
conclude
with these
three rules.
Everything
can be
hacked.
Any
hardware
can be
hacked if
you have
physical
access to
it as
long as
you don't
protect
this
hardware
against
fall
injection.
So you
can put a
lot of
security
in your
device.
protect your
device
physically and
use one of
these
hacking
techniques and
bypass
everything
very easily.
So you
should also
make an
effort to
protect your
hardware
against this
kind of
hardware
hacking
techniques.
The second
rule that
is even
if you
protect
against
fall
injection
your
product,
you have to
keep in mind
that it's
very hard
to do it
and still
you might
be hacked.
And finally,
remember that if
you want to
protect your
product,
you should
always use
hardware and
software
countermeasures.
If you are
interested in
this topic,
this is a
list of
links.
All the
attacks I
have been
talking about
I think is
very interesting.
So if you are
interested,
you can
read this.
And finally,
well, if you are
interested,
we are
hiding.
We have a
security lab
here in
China.
So if
somebody of
you is
interested in
this kind
of
hardware
security
evaluations,
you can
just join
us.
Okay,
thank you.
I think there
is a question
here.
Microphone.
Hi, I'm
just wondering,
I mean,
how practical
is your
approach
to use
the,
I mean,
it seems like
pretty much
Sorry, sorry.
I cannot listen
because the audio
is going in
that direction
and there is a
lot of echo,
so I cannot
hear.
Okay.
I'm just
wondering how
practical is
your approach.
It seems to
be that
you're just
using brute
force to
try different
points to
see if
there is any
possible problem,
I mean,
to inject
the glitch.
Sorry,
again.
How practical
is your
approach?
I mean,
it seems to
me that
you're
using a
brute force
approach to
introduce
the glitch
into the
board.
Okay, yes.
And the states,
yes.
That's correct.
So,
fall
injection
is not
a science.
100%
of possibilities
of succeeding.
So,
it's kind of
brute forcing
in the sense
that you
inject the
glitch and
you try,
try,
try,
try until
you find a
glitch that
flips the
bits in
the way you
are looking
for.
So,
it's kind of
brute forcing.
So,
what we
normally do
is we
have an idea
of what we
want to
do.
We see a
code that
might be
potentially
vulnerable to
fall
injection.
We find with
this instruction
we want to
try to
bypass and
then we try to
inject glitches
in this
instruction and
we try,
try,
try,
try.
We might
have been
trying for
days,
sometimes
weeks because
we need to
know exactly
what is the
glitch,
the length,
the shape
of the
glitch that
affects exactly
the tip in
the way that
we are
looking for.
So,
it's a kind
of brute
forcing until
you find this
perfect
glitch.
After you
have this
glitch,
if you
repeat the
same glitch
you can
get,
well,
a success rate of
100%,
sorry,
1%.
So,
after doing
what we
call
characterization
campaign
where we're
trying to
find the
perfect
glitch that
affects the
tip in
the way we
want,
when we
get this
glitch I
will be
happy if we
have,
yeah,
one glitch out
of 100
works and
break the
product.
But some
devices are
more sensitive
than others.
So,
for example,
most of the
small micro
controllers you
can get a
success rate of
30%.
So,
you can,
one out of three
or four
glitches you
can bypass
whatever you're
trying to.
But some
other complex
chips like a
small,
sorry,
like a big
processor,
like the ones that
you have in a
phone,
it's much
harder.
You need to try
much more.
But yeah,
you have to do a
small brute
forcing until you
find the
exact
glitch that
you need to
do what you're
looking for.
Yeah.
So,
is there
any other
question?
Yes,
I got a second
question.
Is that,
you just
described several
solutions to
protect against
this glitch
attack.
Just one is to
use the
hardware to
use some
redundancy
bits.
And also to
use some
software.
But it seems to
me that you
just,
I mean,
it's still the
same as you
are just trying
to introduce
some redundancy
states.
But since the
state is already
that big,
the program
state is already
that big,
you're just
trying to
And how much,
I mean,
how much safer
would that
make?
Okay.
To be honest,
it's really
impossible to
protect a
product 100%.
So when you
have this
controversy,
you have the
redundancy,
you have the
double checks,
triple checks,
what you are doing
is protect your
product in such
a way that you
reduce the
chances of
being glitched.
But there is always
a possibility of
being glitched.
You cannot
warranty 100%.
You can't
guarantee 99.999%.
There will be
always a small
chance to be
glitched.
The thing is
that you can
protect your
product enough
to demotivate
the attacker.
So the idea
is not to
protect your
product so it's
impossible to
hack it.
It's just that
it's hard enough
to demotivate
the attacker so
he will not
try to attack
your product.
But yeah,
it's really
impossible to
get full
that you will
never be
hacked or
glitched.
So it's like
it's never
possible to be
100% safe.
I mean,
it's never
possible to
be perfectly
safe.
It's not.
From the
theoretical point
of view,
I think no.
From the
practical point
of view,
I think yes.
Because if I need
one year to
hack something,
I will not try,
right?
Yes.
I mean,
if you are
determined enough.
Yeah.
Okay.
I think there
were more
questions.
Two more
questions there.
How practical
is a voltage
attack?
Have you
actually got to
remove the chip
from the circuit
board and able
to get a decent
spike?
Or is there
enough?
How do you
overcome the
capacitance in
the power lines
to prevent you
inserting a
spike?
Sorry,
again.
Do you have
to remove
the chip
from the
motherboard?
Okay.
I did not
talk about
the practical
way to do
the glitching.
So,
yeah,
because I was
talking about
doing
the glitch
by manipulating
the power.
So,
how do we
manipulate the
power?
Okay.
So,
what we normally
do is we are
going to manipulate
the power to do
voltage glitching.
What we normally
do is just we
have manipulated
the PCB,
only the
circuit.
We have to cut
some traces in
the circuit so we
can,
with our
tool,
manipulate,
control the
power.
So, voltage
glitching is very
easy.
You only have
to solder some
cables in the
PCB.
But when we do
all the kind of
glitching,
like a laser,
when we use
the laser,
laser is much
more complicated.
You have to
decap the chip.
You have to open
the chip with
acid,
you decap
the chip,
and then you can
just attack
the chip.
There is some
practical problems,
but,
well,
it's not
really something
that you
cannot work
on.
So, maybe we
can continue with
these questions
of topic,
sorry,
of line.
So, thank you
again for
listening.
And if you want
to see one of
these demos,
please ask me and
I will just show
it to you.
Thanks.
